【Informatica】CIHのトピックに設定できる「増分ロード」、「完全なロード」って何?
はじめに
データ事業本部の川中子(かわなご)です。
先日、園内で様々な動物を飼育している、とある農村公園に行ってきました。
眠そうに日向ぼっこしているカンガルーのお腹を撫でたのですが、柔らかくてとても気持ちよかったです。
...という私の最新トピックはさておき、今回は CIHのトピック設定についてご紹介 です。
リレーショナルタイプのトピックの設定画面で選択できる「トピックタイプ」についてですが、
増分ロード
と完全なロード
の2種類を選択することができるようになっています。
この設定の仕様についてお話したいと思います。
結論
結論から言ってしまうと、どちらを設定しても挙動は変わりません。
こちらの機能については、公式記事のFAQでも以下のような指摘がされています。
FAQ: Does the incremental load option within topic work in Cloud Integration Hub?
The topic doesn't have the associated functionality for incremental load option.
A request has been made to remove this option from UI as this is not working.
Incremental load while supported in DIH, CIH does not currently provide the incremental load functionality.
A Feature request ID: CIH-3086 has been raised to support the incremental load in CIH
内容としては、「増分ロード」のオプションは選択しても特に機能しないので、
UIからこのオプション選択自体を削除してほしい、という内容です。
こちらのリクエストは以下のページで管理されています。
CIH-3086 : Cloud Integration Hub to support Incremental Load
現状(2024/12/04)このリクエストのステータスは完了になっていないので、
Informaticaが必要と判断すれば、今後のバージョンアップでUIから削除されるかも知れません。
データ連携の挙動について
では改めて、CIHではどのようなデータ連携ができるのか、仕様を確認してみます。
こちらも結論から言うと、公式ドキュメントの「完全ロード」が現状の仕様を説明 していると思われます。
Full Load. The topic instance contains all of the data changes that occurred after the last publication.
公式ドキュメントの説明をそのまま読むと、
「最後のパブリケーション以降に変更されたデータを保持する」ということになります。
もう少しユーザー視点で見ると、まだコンシュームされていない全てのパブリケーションが保持 されています。
これはCIHのイベント画面で確認するのが直感的で分かりやすいです。
パブリケーションを実行するとイベント画面にログが表示されます。
まだサブスクリプションが実行されていなければ、コンシュームステータスにチェックがつかずに、
プルダウンで対応するサブスクリプションの遅延ステータスが確認できるようになっています。
複数のパブリケーションを実行した場合も同様で、イベントログが積み重なっていきます。
その状態で対応するサブスクリプションを実行すると、溜まっていたイベントが全て完了ステータスになり、
完了ステータスになったパブリケーションで格納されていたデータがコンシュームできるようになっています。
リポジトリでデータがどのように管理されているか
GUIで全て管理できて、イベントログで直感的にデータ連携の流れを確認できるCIHですが、
念の為リポジトリではどういう形でデータが管理されているのかを見ておきます。
今回はリポジトリの中身を確認するためにプライベートリポジトリを使用しています。
ホステッドリポジトリはクラウド上にデータが格納されるため、直接データを確認できません。
本検証ではリポジトリをRDSで作成して、DBeaverで接続して中身を見ています。
上の画像は適当に作成したサンプルデータを流したものです。
末尾2列はCIHのパブリッシュ時に自動生成される列で、連携データの日時やIDを管理するものです。
データ保持期間外のデータ削除はおそらくこの日時を参照して削除されているのだと思います。
このテーブルは普通にRDSのデータベース上で管理されているデータなので、
SQL文でクエリを投げて任意のデータを取得することなども可能です。
ただ TruncateやDROPを実行するとCIHの挙動に影響を与えるため、極力触らないのが無難 です。
ジョブが失敗した場合のリカバリ方法
せっかくリポジトリのデータ管理の様子を確認できたので、
ここまでの内容を踏まえて、CIHのジョブが失敗した場合のリカバリ方法について考えてみます。
パブリケーション失敗
まずパブリケーションが失敗した場合ですが、これはシンプルに 再実行でOK です。
CIHの仕様として、イベントがエラーになったときには全データが連携されずに終了します。
リポジトリには何も格納されないので、同じジョブを再実行すればリカバリは完了となります。
なお一部データ連携エラーでは、CIHのイベントではエラー扱いにならず、
データベースの仕様によって自動で値が修正されてしまうような例が確認されています。
細かなエラーケースについては以下の記事で紹介しています。
サブスクリプション失敗
次にサブスクリプションが失敗した場合ですが、こちらも基本的に再実行で問題ありません。
サブスクリプションの実行はリポジトリに対して特に影響を及ぼさないため、
失敗した場合も再度実行することで取得予定だったデータを再取得することが可能です。
サブスクリプションの再実行はGUIのトピック編集画面からも可能ですが、
イベント画面のサブスクリプションのイベントログから直接再実行も可能です。
またオフィシャルな方法ではありませんが、前述通り対応するデータベースにもデータが格納されているので、
直接データベースに目的のデータを参照しに行くという方法もあります。
ただこれも前述の通り、CIHのジョブに影響を与える可能性もあるので、あまり推奨ではありません。
もし サブスクリプション以降のデータ連携ジョブなどでエラーが起きた際に、
連携されたデータの調査のためにデータベースを直接参照 するなどの使い方はありかも知れません。
まとめ
以下の本記事に記載した内容を簡単にまとめてみます。
- トピック設定の トピックタイプはどちらを選択しても機能に差はない
- 増分ロードはUIから削除する旨のユーザーリクエストが起票されているが、現在は未対応
- データはイベント画面で確認できる イベント単位でパブサブ連携ができる
- プライベートリポジトリなら連携されたデータをデータベースで直接閲覧、操作 ができる
- ジョブが失敗した場合は基本的に 再実行することでリカバリ可能
みなさんがCIHの設定をする際に参考になれば幸いです。
最後まで記事を閲覧頂きありがとうございました。